Discovering the Microsoft Azure Platform

• Windows Azure. A collection of virtual Microsoft operating systems that can run your web applications and services in the cloud. For example, you can create a web service that converts US dollars to Euros; then, you can deploy the service on Windows Azure and allow it to scale as needed. Note that Windows Azure can run .NET applications and other platforms as well, including PHP.

• Windows Azure AppFabric. A set of services that provide core capabilities such as federated identity for access control, and a service bus for a messaging-based subscriber/publisher topology.

• SQL Azure. Microsoft's transactional database offering for cloud computing based on Microsoft SQL Server 2008. For example, you can store your customer database in the cloud using SQL Azure and consume customer data using services deployed in Windows Azure.

Figure 1 shows a simplified corporate environment connecting to the Microsoft Azure platform and consuming all three services. This diagram is overly simplified, but it conveys an important message: Microsoft Azure is designed to extend a corporate environment securely for web applications, services, messaging, and data stores.

Figure 1. Microsoft Azure platform overview

1. Why Microsoft Azure?

One of the fundamental questions that's frequently asked is, "Why?" Who's interested in developing applications in Windows Azure in the first place? To answer this question, let's look at the evolution of web platforms.

About 15 years ago, when the public Internet was all about bulletin board systems (BBBs), Gopher services, and $500 9600-baud modems, the question was, "Will the Internet stick as a technology?" That question has been answered, but many new concepts have grown since then, including web sites, hosting centers, and SaaS.

This evolution relies on a common theme: decoupling. BBSs decoupled public information from libraries; web sites decoupled user interfaces from computers; hosting centers decoupled hardware from a company's own infrastructure; and SaaS decoupled complex applications from corporate computers.

Cloud computing on Microsoft Azure is a natural evolution of computing flexibility in which the actual physical storage and implementation details are decoupled from the software solution. For example, deploying services in Windows Azure doesn't require any knowledge of the machine running the service or any of the core services (IIS version, operating system patches, and so on). You may never know which machine is running your software. Connecting to a Windows Azure server is performed through logical names, just like connecting to SQL Azure.

The ability to disassociate machines from data and services is very powerful in itself. Although it's still an early-stage platform, Microsoft's Azure environment allows multiple business scenarios to flourish, including these:

• Seasonal applications. Developing web sites or services that have a tendency to grow and contract over time provides potential savings opportunities because cloud computing uses a pay-as-you-use model.

• Short life span. Development of prototypes or applications with short lifespans is also attractive, such as event-registration sites. You can also build development and test environments for remote teams.

• Split storage. Certain applications need to keep storage in a safe location but may not require frequent access, or may require high availability. Designing or modifying an application so that the data is stored locally and in SQL Azure (or other data-storage formats) may make sense.

• Small companies and ISVs. Smaller companies that can't afford large and complex infrastructure to start their business can take advantage of the financial and inherent infrastructure benefits of Microsoft Azure. Independent software vendors (ISVs) can also benefit from cloud computing. For example, an ISV can use SQL Azure to store application logs or centralize reporting features from multiple disconnected locations.

2. About Geographic Locations

In order to provide high availability, Microsoft established regional data-center operations that allow customers to select geographically dispersed services. When you create your Azure servers, you need to specify which geographic location the servers should be provisioned in. This feature is called Windows Azure geolocation.

Initially, it may be tempting to choose your company's geographic location for improved performance. However, if the availability of your Azure services is more important than response time, you may need to pick another location. When selecting a geographic location, make sure to consider the following:

• Performance. When your data is closer to your users, network latency may be noticeably lower, improving customer experience.

• Disaster recovery. If ensuring the availability of your cloud platform is important, you may want to disperse your services and data across multiple regions.

• Legal factors. Consider the type of information that will be stored in the cloud, and ensure that you aren't bound by specific regulations and mandates that may prevent you from selecting remote geographic locations.

At the time of this writing, you can select from one of the following geographic locations, each of which is supported by a regional data center:

• Anywhere Asia

• Anywhere Europe

• Anywhere US

• North Central US

• North Europe

• South Central US

• Southeast Asia

In addition, you can create an affinity group that lets you keep certain Azure services together. Such a group creates a geographic dependency between Windows and data services deployed in the Microsoft Azure platform. If Microsoft is obligated to move a service to another geolocation for regulatory reasons, the related services will likely move along. For example, if you develop an Azure service that depends on a SQL Azure database, you may want to ensure that they both reside in the same geolocation and that they belong to the same affinity group.

Additional locations will be added over time. As a result, you may need to reevaluate on a regular basis whether a service is deployed in the most appropriate geographic location.

3. Storing Data in Azure

As you can imagine, cloud computing is all about storing data in a simple yet scalable manner. The Microsoft Azure platform doesn't disappoint and offers a variety of storage models that you can choose from. This section summarizes the four ways you can store your data in Azure; three of these approaches are considered part of the Azure services.

Figure 1-2 provides an overview of the storage options and the available access methods. The set of storage options provided by Windows Azure is referred to as Windows Azure storage, which includes blobs, tables, and queues. Windows Azure storage can be accessed directly from a corporate environment using HTTP/S calls, providing a simple hook into the Microsoft Azure platform. In addition to using Windows Azure storage, consumers can make requests directly to a SQL Azure database using ADO.NET or ODBC, because SQL Azure supports the Tabular Data Stream (TDS) protocol that SQL Server uses. As a result, applications and services connecting to a SQL Server database can just as easily connect to a SQL Azure database.

Figure 2. Microsoft Azure data storage access

Following are further details of the four storage types:

• Azure services storage. The Azure services offer three distinct storage models that are tailored to specific needs:

  • Table. A named value-pair storage that allows you to store very large amounts of data. This storage model includes automatic load balancing and fail-over. It's called a table because you can store multiple values in each row. However, this isn't a transactional storage mechanism; no indexing or table joins are possible. Also, the columns defined in a table have storage limitations. For example, a string data type is limited to 64KB.

  • Blobs. An interface to store files, with a maximum limit of 50GB of storage for each blob. You can easily access blobs using a straight HTTP request through a Representational State Transfer (REST)) call.

  • Queue. A highly available mechanism for storing messages for consumption by other applications or services. A typical usage of queues is to send XML messages. Certain limitations apply to queues, but you can access queues through REST as well.

• SQL Azure. SQL Azure is a transactional database that provides familiar data access through ADO.NET or other providers and gives you the ability to manipulate the data using standard T-SQL statements. Databases in SQL Azure are limited to either 1GB or 10GB, depending on the edition selected.

Table 1 summarizes the current characteristics of these data-storage options available in the Azure platform.

^[] Recommended limit